Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add gc option and nil for grace_time option #4

Merged
merged 2 commits into from
Feb 12, 2019

Conversation

aishek
Copy link

@aishek aishek commented Feb 2, 2019

Good evening and thanks for useful gem!

I've got two special use cases for the gem: restart as soon as possible, and wait all jobs to finish without timeout. So I implemented gc: false option and grace_time: nil.

How it looks like? What should I change?

Copy link
Collaborator

@BuonOmo BuonOmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for enjoying this gem. And thank you even more for participating in it!

I made a few remarks in the code that are hints for tiny enhancements, but the way your implementation is made is clean enough in my opinion.

However, the grace_time: nil option feels a bit weird IMHO. I mean, say you have an infinite job that takes all your resources, you would maybe like sidekiq to wait a lot but at some point, it should restart anyhow. You could then have a really long time set instead of nil (1.day.to_i for instance).

@@ -12,17 +12,20 @@ class WorkerKiller

def initialize(options = {})
@max_rss = (options[:max_rss] || 0)
@grace_time = (options[:grace_time] || 15 * 60)
@grace_time = (options.key?(:grace_time) ? options[:grace_time] : 15 * 60)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to have a consistent way of initializing variables here. This said I'd lean more in favor of the #key? option since it avoids unexpected behavior such as:

expect_false_but_obviously_is_true = false || true
# This would impact the `gc` option for instance

What do you think?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right. It is my bad. Best option is options.fetch(:grace_time, 15 * 60), and it is supported since Ruby 2.0.0. I'll change to consisted way here.

expect(GC).to receive(:start).with(full_mark: true, immediate_sweep: true)
subject.call(worker, job, queue){}
end
context "but gc is false" do
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our codebase, we tend to prefix context elements with when.

Suggested change
context "but gc is false" do
context "when gc is false" do

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will fix it.

@aishek
Copy link
Author

aishek commented Feb 4, 2019

However, the grace_time: nil option feels a bit weird IMHO. I mean, say you have an infinite job that takes all your resources, you would maybe like sidekiq to wait a lot but at some point, it should restart anyhow. You could then have a really long time set instead of nil (1.day.to_i for instance).

I agreed that it is weird. My assumption is you have no infinite jobs in the application. It is very useful for my case.

Copy link
Collaborator

@BuonOmo BuonOmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, let's go for that option. Since this isn't the default behavior, it should mean that someone that sets grace_time: nil knows what he is doing.

@aishek, could you do a last rubocop check / commit squash before I merge?

Thank you very much for this improvement 🎉

@ccyrille
Copy link
Contributor

ccyrille commented Feb 12, 2019

I completely agree with gc: false, thanks @aishek !

However, seems to me than setting nil for an infinite grace_time is counter-intuitive (I would expect to have no grace time while passing nil). Why not simply use Float::INFINITY to have an infinite grace time ?

@aishek
Copy link
Author

aishek commented Feb 12, 2019

@ccyrille Thanks for the suggestion, Float::INFINITY is the best fit here.

@BuonOmo I've run rubocop check and squashed commits to single.

@BuonOmo BuonOmo merged commit 5816b7c into klaxit:master Feb 12, 2019
@aishek aishek deleted the more-options branch February 13, 2019 06:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants